-
Notifications
You must be signed in to change notification settings - Fork 34
Refactor fmpz_mpoly and fmpq_mpoly arithmatic functions #190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
b16f140 to
5f80eff
Compare
|
This is now rebased on master |
| def any_as_scalar(self, other): | ||
| if isinstance(other, int): | ||
| return any_as_fmpq(other) | ||
| elif typecheck(other, fmpz): | ||
| return any_as_fmpq(other) | ||
| elif typecheck(other, fmpq): | ||
| res = fmpq.__new__(fmpq) | ||
| fmpq_set((<fmpq>res).val, (<fmpq>other).val) | ||
| return res |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is an fmpq already can we not just return it?
Why does a copy need to be made?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it best to be consistent with the other any_as_* methods, but since they are immutable on a python-flint level perhaps we can just return the same object.
any_as_fmpq is just not used there because no conversion is required
>>> from flint import *
>>> x = fmpz(1)
>>> y = any_as_fmpz(x)
>>> x is y
False(With any_as_fmpz modified to be a cpdef)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe any_as_fmpz should be changed to not make a copy. I'm not sure that is compatible with how it is currently used though like whether the object returned is ever mutated.
|
|
||
| def __pow__(self, other, modulus): | ||
| def _add_mpoly_(self, other: fmpq_mpoly): | ||
| cdef fmpq_mpoly res |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe these methods should all be cdef.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just tested this locally and it's possible, just needed a little massaging due to C-methods not being visible at runtime. The non-commutative operands can't use runtime reflection after coercion anymore, it needs a explicit C reflected function e.g. _rtruediv_mpoly_ which can just call the normal C _truediv_mpoly_ after a cast + argument swap. Will have this up this evening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually should just be able to use the normal dunder methods after the coercion rather than have a reflected cdef. Though using the cdefs all the way down is probably slightly faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
This looks good. Improvements can always be made later. |
This refactors fmpz_mpoly and fmpq_mpoly to use the new mpoly structure added in #164. It is based on #189, I'll rebase this PRs one real commit once #189 is merged